1. Field of the Invention
The present invention generally relates to a system and method for processing checks and, more particularly, to a check exception item notification system and method which provides a client with notification of exception items through e-mail.
2. Description of the Related Art
The financial services industry has long provided its customers with the ability to write checks and similar negotiable instruments. In current practice, a payor (e.g., a client of a bank or financial institution) writes a check representing an amount to be deducted from the payor's account. The check is given to a payee. Checks are normally presented for payment by the payee to the payee's banking institution (the “payee bank”). In turn, the payee bank presents the check to the payor's bank for payment. The payor's bank then pays the payee bank, and deducts the amount of the check from the payor's account, against which the check is drawn.
In order to prevent fraud and/or mistakes, most banks with large institutional clients offer these clients a service known as check exception processing. Large institutional banking clients issue a significant volume of checks on a daily basis. For example, an insurance company might issue several thousand checks in a single day in the course of processing insurance claims. The client provides the bank with a file listing information of all of the checks that it has issued (an “issue file”) to payees. In performing the exception processing, the bank compares the checks issued by these clients with the checks that are presented for cashing by the payee bank.
When the payor bank receives a request for payment from the payee bank with respect to a check presented by a payee, the payor bank will then compare the information on the presented check with the issue file using, for example, the magnetic ink character recognition (“MICR”) line. When a check is issued by a payor, a MICR line is usually added to the check and includes the check number and the payor account number. When the payor bank processes this check, the amount of the check is also added to the MICR line. If the payee check matches with a check in the issue file, (e.g., if the amounts, and check numbers match) the payor bank has confidence that the presented check is valid and pays the payee's bank. If the payee's check does not match any item in the issue file, the payee check is labeled an “exception item”. Each business day, the payor bank provides the client of the exception service with a list of the exception items and inquire as to whether the client is interested in paying each exception item.
Prior art methods for actually notifying clients of exception items have not satisfied the needs of clients who have large numbers of checks written each day. For example, typical prior art notifications include CD-ROMs containing exception check images or reports, digital image microfilm, dial-in online access using bank proprietary software, facsimile, telephone, paper, tape and transmission index reports. Some systems allow the bank's client to connect to the bank system electronically through a network such as the Internet and view exception items.
In most of these network connections, the list of exception items is “dirty” or “unscrubbed” in that the items are typically the result of an electronic mismatch and not reviewed by bank personnel before the clients are allowed to view the exception items. This means that the exception list may include mis-encoded items, duplicate items, or items with stop payment instructions already on file. Mis-encoded items include checks where an operator keyed in the incorrect dollar amount or check serial number in the MICR line even though the dollar and check serial number fields on the face of the check are correct. In addition, in most prior art systems, the exception client is not shown an image of the exception check. Such an image must be requested separately and so the exception client typically does not have enough information to determine whether to authorize or decline payment of the check.
Therefore, none of these prior art methods and systems can satisfactorily handle the massive influx of checks and exception items produced daily by large institutions. Nor can these prior art systems handle the need of large institutions to have a list of “true” suspect items (i.e. an exception list that is “clean” or “scrubbed” to remove mis-encoded items, duplicate paid items, and items with stop payment instructions on file). Moreover, prior art systems do not provide corresponding gray-scale images of check exception items so that the client has all available information to make an accurate determination as to whether to authorize or decline payment of an exception item.
Further, in the systems where a form of media is sent to the client, there is necessarily a delay between the production of an exception item, and notification of that exception item to a client. A defined period of time must pass before a bank ceases gathering exception items to be included in the media (e.g., CDROM, paper, etc.) and subsequently sent to the client. Thereafter, the media must be physically sent to the client thereby incurring further delays. Finally, there may be a delay in the client's response as to whether the exception item should be paid. Such delays are undesirable because banks must meet a deadline established by the U.S. Federal Reserve Bank (“Fed”) to submit all “return” items (those items identified by the client as suspect or fraudulent) that should be sent to the payee bank for credit. Clearly it is desirable to provide client's of the payor bank with as much time as possible to determine why a particular item is an exception item.
Therefore, there exists a need in the art for a system and method of providing clients with notification of check exception items which is faster, more efficient, and easier to use than the techniques of the prior art.